Add Book to My BookshelfPurchase This Book Online

Chapter 5 - Adding Support for Legacy LANs

Cisco TCP/IP Routing Professional Reference
Chris Lewis
  Copyright © 1999 The McGraw-Hill Companies, Inc.

Networking Windows NT
Windows NT has the fastest-growing market share of any network operating system (NOS) currently in the market. It seems that Microsoft has finally produced a NOS with which to challenge the leadership position of Novell's NetWare. NT bases much of its LAN communication on NetBEUI, the NetBIOS Extended User Interface, which is a legacy from Microsoft's LAN Manager and IBM's PC LAN products. NT, however, has built into the operating system the ability to interface to IPX/SPX, TCP/IP, and DLC (Data Link Control).
I will not go into the details of setting up these protocols using Windows NT utilities; there are plenty of Microsoft manuals and Microsoft Press publications to do that for you. What will be covered here is an overview of what NT servers use to communicate network information, and what the options and issues are for interconnecting NT servers and workstations over a WAN.
Windows NT Network Protocols
In this section we will examine the transport protocols of Windows NT, which are NetBEUI, NWLink, TCP/IP, and DLC.
NetBEUI.     NetBEUI originally was designed for small LANs of around 20 to 100 workstations. As such, it was not designed with any concept of network numbers and is therefore a nonroutable protocol. Windows implements NetBEUI 3.0, which uses the NetBEUI Frame (NBF) protocol that is based on the NetBIOS frame type and therefore is compatible with previous versions of NetBEUI.
In communications based on NetBIOS, computers are referred to by name rather than address. Packets on the local segment are still delivered by MAC address, with each station on the network maintaining a computer-name-to-MAC-address translation. On a single LAN segment, NetBIOS communications deliver better performance than a routable protocol because the communication process is simpler. These days, however, there are very few networks installed that only ever need to connect to fewer then 100 other computers. Recognizing the problems of NetBEUI in larger environments, Microsoft chose TCP/IP as its strategic WAN protocol for Windows NT implementations.
NWLink.     NWLink is the native Windows NT protocol for Novell's IPX/SPX protocol suite. NWLink provides the same functionality that IPX.COM or IPXODI.COM files did for a machine using the Open Data Link Interface (ODI) specification, namely the ability to use IPX as a transport protocol. To connect to a NetWare server requires the use of VLM programs for an ODI machine, or the Client Services for NetWare (CSNW) redirector for Windows NT.
NWLink is useful if you have a mixed environment of NT and NetWare servers and need an NT machine to communicate with both.
TCP/IP.     In the Windows NT world, TCP/IP is used as a transport protocol, primarily for WAN connections. Later in this section we will be discussing functions of the NT server that generate network traffic, most of which can be encapsulated within TCP/IP. This is useful for minimizing the number of protocols that need to be supported on the WAN, but can be an issue if the encapsulated NetBEUI traffic starts to reach significant levels. We will discuss this later.
The NT implementation for TCP/IP includes SNMP and DHCP support, as well as the Windows Internet Name Service (WINS), which maintains a central database of computer-name-to-IP-address translations. NetBT, which stands for NetBIOS over TCP/IP, also is supported by NT for NetBIOS communication with remote machines via encapsulation in TCP/IP.
Data Link Control.     An important difference between DLC and the other protocols supported by Windows NT is that DLC is not meant to be used as a primary means of workstation-to-server communication. That's because DLC does not have a NetBIOS interface. Even when other protocols such as TCP/IP are used for workstation-to-server communications, a NetBIOS interface is needed to encapsulate NetBIOS traffic within this other protocol, just as NT computers need to pass NetBEUI among themselves to function.
The DLC protocol needs to be implemented only on machines that either access IBM mainframes using certain emulation packages, or print to some older types of Hewlett-Packard printers.
Windows NT Network Traffic
In the world of NetWare servers, we saw that SAP advertisements primarily, and RIP updates secondly, are the means by which the NOS itself steals available bandwidth from the applications we wish to run over our internetwork. SAP and RIP were designed to advertise servers, available services, and the means to get to those services. In the world of Windows NT, there is the browser service that performs an equivalent function.
In our discussion of optimizing NetWare protocols for transmission over WANs, we saw that the Cisco IOS had many options for directly controlling the propagation of IPX SAP and RIP packets, because IPX is a routable protocol. Because the Windows NT browser service is based on NetBEUI transport, which is not routable, there is no opportunity for such a fine degree of control over the propagation of these packets by the Cisco IOS. We will, however, discuss the options for maintaining browser service over WAN links.
Windows NT Browser Service Overview.     The Windows NT browser service is available to enable the sharing of resources across the network. This is achieved by the election of  master and backup browser servers on each network segment. The browser servers keep track of shareable services on the network, and client computers query the browser servers to see what is available. The types of network traffic that this process generates are illustrated as follows.
  Each potential browser will advertise its candidacy via browser election packets, and an election process will take place to determine which machines become primary or backup servers.
  The master browser sends to backup browsers a new list of servers every 15 minutes.
  Nonbrowsers, potential browsers, and backup browsers announce their presence every 1 to 12 minutes.
  Workstations retrieve shareable resource information from their backup browsers on an as-needed basis.
Let's examine these concepts a little more closely.
Browser Types.     A browser is a computer that holds information about services on the network, file servers, printers, shared directories, etc. The job of providing a browser service to nonbrowser machines is spread among several computers on a network, as defined in the following:
  Master browser maintains a list of all available network services and distributes the list to backup browsers. No client machine requests information directly of the master browser; client machines only request information directly from backup browsers. For each Windows NT workgroup or domain defined, there is only one master browser per Windows NT Workgroup or Domain.
  Backup browsers receive a copy of the browser list from the master browser and send it to client computers as requested.
  Potential browser is a computer that could be a browser if so instructed by the master browser.
An election process takes place to determine which computer will become the master browser and which computers will become backup browsers. An election is forced if a client computer or backup browser cannot locate a master browser, or when a computer configured to be a preferred master browser is powered on. The election is initiated by the broadcasting of an election packet to all machines on that network. The election process ensures that only one computer becomes the master browser; the selection is based on the type and version of the operating system each machine is running.
Browser Traffic.     Assuming that browser election has taken place and the master browser and backups are operational, we can describe the traffic generated by the browser as follows.
After the initial boot sequence, a computer running the server process (workstations can run this process in addition to NT servers), will announce its presence to its domain's master browser. This computer is then added to the master browser's list of network services available. The first time a client computer wants to locate a network resource, it will contact the master browser for a list of backup browsers, and requests the list of network resources (domains, servers, etc.) from a backup server. The client computer now has what it needs to view, select, and attach to the available network resources.
The client PC now has a list of available resources. What happens if one of those resources becomes unavailable? There are browser announcements going on continually on a network. These announcements are similar in concept to routing update advertisements, i.e., as long as a router continually advertises route updates, it will still be considered usable by the other routers. Similarly, as long as a browser or server announces itself periodically, it will be considered available; if it stops announcing itself, however, it is deleted from the network resource list.
Initially every computer on the network will announce itself every minute to the master browser, although eventually this period is extended to 12 minutes. Backup servers request an updated resource list from the master browser every 15 minutes. When a master browser wins an election, it will request all systems to register with it. Systems will respond randomly within 30 seconds, to stop the master browser from becoming overwhelmed with responses.
If a nonbrowser machine fails, it could take up to 51 minutes for the rest of the machines on the network to find out about it. If a nonbrowser or backup browser computer does not announce itself for 36 minutes (three announcement periods), the master browser deletes it from its network resource list. It can take up to 15 minutes for this change to be propagated to all backup browsers. In the case of a master browser, the failure is detected the next time any machine tries to contact the master browser, and an election immediately takes place.
In addition to this traffic, master browsers broadcast network resource information between domains as well as within domains every 15 minutes. If a master browser that is sending its network resource information to another domain fails, it will take 45 minutes for that network resource information to be deleted from the domain receiving that information. Basically, a master browser will wait for three announcement periods before it deletes resource information coming from another domain.
Transporting Windows NT Traffic over a WAN
We have seen that in a Windows NT-based network there is a lot of broadcast NetBEUI traffic that essentially is using NetBIOS frame types. NetBEUI is not routable, so should we connect sites together on a WAN-based network on Data Link level bridges?
I would not recommend it. We covered the issues of bridge-based networks earlier in this chapter, and outlined why building networks based on Data Link layer bridges is no longer popular.
We have two options, the first of which is the use of DLSw to transport the NetBIOS frames over the WAN links. The second is the use of a WINS server that will use unicast TCP/IP packets to announce specific services to prespecified servers across an IP WAN.
Connecting NT Networks via DLSw.     Earlier we discussed using DLSw as a technology to carry Token-Ring-based NetBIOS traffic over TCP/IP WANs. This can be extended to the case for transporting NetBEUI traffic between Ethernet LANs via a TCP/IP WAN relatively easily. A typical internetwork for supporting this type of connectivity and corresponding router configurations are shown in Fig. 5-24.
Figure 5-24: Transporting Ethernet-based NetBEUI packets over a router-based
We need to achieve a tunnel between router 1 and router 2 that will transport any NetBEUI packet between LAN 1 and LAN 2. The configuration for router 1 and router 2 to achieve this is given in Fig. 5-24, which we will discuss line by line.
The following commands configure router 1 for passing NetBIOS packets via DLSw over a TCP connection.
  Command dlsw local-peer peer-id 162.8.5.1 enables DLSw on the router and identifies the interface with IP address 162.8.5.1 (in this case the Ethernet 0 interface) as the one being presented with NetBIOS packets.
  Command dlsw remote-peer tcp 162.8.6.1 identifies the IP address of the remote device with which to exchange traffic
  using TCP. In this case, it is the Ethernet interface of router 2. In essence, the local peer and remote peer identify the two ends that will use TCP to carry NetBIOS packets between them.
  Command dlsw bridge-group 1 is used to enable DLSw+ on the Ethernet interfaces that are assigned membership of bridge group 1 in interface configurations. In effect, DLSw+ is attached to a transparent bridge group, meaning the NetBIOS packets are exchanged transparently between all members of the bridge group.
  Commands interface ethernet 0 through bridge-group 1 identify this Ethernet interface as participating in the transparent bridge group 1.
The commands for router 2 are basically a mirror image of the commands entered for router 1, and you can see that the local peer for one router becomes the remote peer for its companion router, and vice versa.
This method of providing NetBIOS connectivity over a TCP connection works, but does not give you much control over which NetBIOS packets get forwarded and which do not. If there are multiple NT servers at each location, all the NetBIOS packets they generate will be forwarded over the link whether you want them to be or not. A slightly better option is to use the facilities within Microsoft's software to encapsulate NetBEUI traffic within TCP/IP directly within the NT server itself.
Using WINS to Announce Services Over an IP WAN.     At the most basic level, a NetBIOS-based application needs to see computer names, while IP devices need to work with IP numbers. If the communication medium between two machines trying to communicate with each other via a NetBIOS- based packet is an IP network, there must be a mechanism for mapping NetBIOS names to IP addresses and converting the IP addresses back to NetBIOS names. This mechanism is the NetBIOS over TCP/IP protocol, otherwise known as NBT.
There are four types of node defined in NBT: the B, P, M, and H node. The B node issues a broadcast on the network every time it needs to locate a computer on the network that owns a given NetBIOS computer name. A P node uses point-to-point directed calls to a known NetBIOS name server, which will reply with the node address of a specified computer name. The M node is a mixture of B and P node operation. An M node will first issue a broadcast to locate a machine, and if that fails, it will query an identified name server. The H node does things the other way around, i.e., it will contact a known name server first, and if that fails, send out a broadcast to locate a host.
This procedure is similar in concept to how IP hosts resolve host names to IP addresses. An IP host will refer to either a local hosts file or a DNS server to resolve a hostname to an IP address. NetBIOS-name-to-IP-address resolution is executed by a broadcast, reference to a local LMHOSTS file or a central Windows Internet Name Service (WINS) server.
The order of search used by Microsoft clients for NBT name resolution is as follows:
  1. The internal name cache is checked first.
  2. NBT queries the WINS server specified in its configuration.
  3. A broadcast is issued.
  4. NBT searches the locally defined LMHOSTS file.
  5. NBT issues a DNS query to a DNS server for name resolution (a last-gasp effort!).
The LMHOSTS file is a flat ASCII file that looks very similar to the hosts file used by IP nodes. A typical LMHOSTS entry is shown as follows.
My_server #remote server
The 193.1.1.1 is the IP address of the computer using My_server as a NetBIOS name, while comments follow the # character.
Interestingly, NetBIOS does not use port numbers to identify processes running within a host. Each process running in a host must be assigned a different service name and have a separate entry in the LMHOSTS file. So if My_server is running an SNA gateway application and a client/server application, it will need two entries in the LMHOSTS file, each one mapping the appropriate NetBIOS service name of the application running to the IP address 193.1.1.1. In this respect, the IP model is more efficient because only one entry per machine needs to go into the host's file, and any applications running within a host are identified by port number by the transport layer protocol.
Managing LMHOSTS files distributed all around an internetwork presents the same problems as managing distributed hosts files. WINS was implemented as a service to offer the same functionality as DNS by providing a central repository for name resolution information. WINS is a proprietary Microsoft technology, and therefore does have some nicely integrated features if you are using an NT server. For example, if you are running both WINS and DHCP from the same
NT server, WINS can read the DHCP databases to find out the NetBIOS names and IP addresses registered. A client configured for WINS and DHCP will also register coordinated computer name and IP address information as it comes online.
What all this means to a real internetwork is that by implementing either a WINS server or LMHOSTS file, and loading the NBT protocol on NT servers, you can have announcements made by NT servers over an IP network. Let's look at maintaining browser functionality if you have NT servers at distributed locations, interconnected by an IP WAN as shown in Fig. 5-25.
Figure 5-25: IP WAN connectivity in a Windows NT environment
In Fig. 5-25 we assume that server 1 is running WINS and the workstations on that LAN are configured to use it for IP name resolution. With a default workstation configuration, WS1 will be able to contact directly any computer on LAN 1 and any remote computer with an IP address and name defined in the WINS server. Remote services, such as server 2, need to be configured to register with the server 1 WINS process. In a large environment, having all services register with one central WINS server and keeping their listing alive with regular announcements can become burdensome. To counter this issue, Microsoft enables a distributed WINS strategy to be implemented, in much the same way that DNS operates as a distributed database.
Whichever way you choose to enable NT computers to use the browser service over a WAN, WAN bandwidth will be consumed. Every network mechanism uses some bandwidth to maintain information about connections. In each of Windows NT browsing, NetWare SAP/RIP or IPXWAN and NLSP, or IP routing protocols such as IGRP and OSPF, it comes down to how you configure the services for your particular installation. All of these options can work in the vast majority of cases.
Implementing Quality of Service Features
In this section we'll look at some of the newer protocols that have been developed to add a degree of service guarantee to protocol designs that did not originally consider such concepts.
In the world of LANs, Ethernet seems to have won the battle for the hearts and minds of network managers over token ring (occasionally referred to as broken string). Despite advances such as early token release and token switching, token ring has not been able to keep pace with Ethernet technology; switched segments, 100 Megabit per second Ethernet and the looming gigabit Ethernet. I side with the majority and believe that this is the right thing, however, token ring by its nature is deterministic, whereas Ethernet is not, which raises issues when we start to consider guaranteeing network performance.
By design, Ethernet creates all nodes on the network equal in terms of their access to network resources. Any device that wants to send data on the network can do so at any time, as long as no other device is transmitting. This is a good thing for data-oriented networks. Increasingly, however, organizations are looking to leverage the investment made in Ethernet networks to deliver multimedia audio and video applications to the desktop. These sophisticated multimedia applications need guaranteed amounts of bandwidth and fixed latency to operate well, presenting some significant challenges to the basic Ethernet protocol.
Background Considerations.     To guarantee network performance, for specific traffic streams, you must dedicate some network resources to those streams. An Ethernet network does not distinguish between packets carrying a videoconference, access to a mission critical database, game data or Internet information. Currently, Ethernet cannot deliver service guarantees for two reasons. First, the only restriction on any node seeking to gain full access to Ethernet's 10-Mbps throughput is that no other node can be using the network at that time. If a node transmitting non-critical data wants to launch a large file transfer that will funnel resources from critical network traffic, it can. Second, Ethernet packets are of varying lengths; it takes anywhere from 51.2 microseconds to 1.2 milliseconds to transmit an Ethernet frame onto a network cable. As a result, critical data will face uncertain delays.
Proponents of ATM say these challenges to performance guarantees on Ethernet are so fundamental to the way Ethernet operates that it is not feasible to use Ethernet for multimedia applications that require such guarantees. The Ethernet crowd counters this by noting improvements in Ethernet bandwidth and other advances such as the Resource Reservation Protocol (RSVP), the Real-time Transport Protocol (RTP) and IPMulticast.
In practice, most engineering decisions are a compromise. In this case, the pluses for Ethernet are that it has a huge installed base, most network administrators understand its operation, and it is significantly cheaper than competing technologies. Grafting performance guarantee capabilities onto Ethernet produces a theoretically sub-optimal solution, but one that is good enough for most users.
On a theoretical level, ATM has two features that make it a technology more appropriate for delivering performance guarantees. First, ATM uses a fixed cell length, which reduces latency in switches and reduces variable delays in the network. By having a fixed cell (a cell is equivalent in ATM terms to an Ethernet packet) length, switching of cells can be done by hardware, which is much faster than software, as there is no fragmentation and reassembly of packets to worry about. Second, ATM is most commonly a connection-oriented technology that uses a call setup procedure for every conversation, which gives the network an opportunity to guarantee performance levels during call initiation. Calling ATM a connection-oriented technology does not mean that it is a reliable delivery mechanism like the LAP-B data-link protocol found in X.25. There are no cell-recovery procedures because ATM leaves retransmission to higher-layer protocols. ATM performance guarantees are managed by a traffic contract that is negotiated during call setup between the network and the device requesting the connection. The device requesting connection will ask for one of four classes of service, and the network either will agree to this service level and permit the connection or the connection will be denied. The traffic contract places demands on the call-initiating device; if it tries to send more traffic than originally stated, the excess traffic may be discarded by the network.
RSVP, RTP, and IP Multicast.     Delivering high-quality audio and video over Ethernet networks requires performance guarantees, which are provided by a combination of the RSVP, RTP, and IP Multicast capabilities.
RSVP has the job of reserving a specific bandwidth for a stream of data on the network. This is complemented by RTP, which minimizes the effects of packet loss and latency (packet delay) on audio and video content. IP Multicast enables the machine originating the traffic flow for audio or video content to send the stream only once, no matter what the number of receivers, or the subnet on which they are located.
To reserve a given level of bandwidth end to end, all devices in the chain from source to destination must support RSVP. In practice, an RSVP-enabled host will request a certain service level from the network, essentially a performance guarantee from all the routers in the path from source to destination. The network will either agree to this request and reserve the requested bandwidth or terminate the requested session.
Within the RSVP host software, admission control and policy control modules are executed.
Admission control determines if the node can obtain the requested resources necessary to meet the requested performance level on the network at that time. Policy control checks whether the application has administrative permission to make this reservation. If both these checks succeed, the host RSVP software sets parameters in a packet classifier and packet scheduler to obtain the desired performance level from the network. The packet classifier defines the service level for every packet, and the packet scheduler orders packets for transmission to obtain the network resources. The RSVP request for a given performance level is made by an RSVP aware application (in the Microsoft Windows world, this is made via calls to the WinSock 2 library), requesting that a certain service model define the bandwidth required or the delay that can be tolerated.
In practice, only two service models are widely deployed: guaranteed service and controlled-load service. The guaranteed-service model ensures that the delay restrictions requested by a host originating an RSVP call are met. The controlled-load service model makes no guarantees, but admits new RSVP connections only up to the point where service starts to deteriorate. Beyond that, new connection requests are denied.
Controlled load was the model implemented by Cisco when it demonstrated its RSVP offering at the NetWorld1Interop show. Using an RSVP-enabled version of Intel Corp.'s ProShare presenter application displaying video, an RSVP session was established through an internetwork of Cisco routers, and the videostream remained intact. With RSVP disabled, the video stream through the internetwork was disrupted and did not display properly.
RSVP is not a routing protocol and does not calculate appropriate routes to take through an internetwork. It uses routing table entries generated by other protocols, such as the Routing Information Protocol (RIP) or Open Shortest Path First (OSPF), to determine the next router in sequence to deliver packets to. As such, RSVP will adapt to new routes as they appear.
It must be conceded that RSVP works better over point-to-point links than over LAN connections. This is because the network represents a queue of data that is not directly under the control of the device making RSVP guarantees. For example, a router can offer guarantees for one RSVP stream on one connected network, but the router does not know the loads or the timing of those loads that neighboring systems will present.
RTP is an applications-layer protocol that uses time stamps and sequence information in its header to recover from delay variations and packet loss in a stream of traffic transmitted on an internetwork. An RTP session works best when established within an RSVP connection (see Fig. 5-26). In this arrangement, the RSVP connection is established by a network device requesting a performance level from the network. Once this RSVP connection is established, the application in the device requesting the connection can use RTP to deliver video and other delay-sensitive data. As a network administrator, you would be involved only in setting up RSVP parameters. RTP operation is in the realm of application programmers.
Figure 5-26: Illustrating the concept of an RTP stream operating within an RSVP envelope.
Multicast is fundamentally different than unicast (point-to-point) and broadcast communications. Central to the theme of multicast communication is that a recipient has to initiate the process of joining the group of hosts receiving a specific multicast. The multicast is sent once by the originator, it is routable (pure broadcasts by default, are not), and is not sent to segments where hosts have not registered to receive the multicast.
Implementation Issues.     To successfully implement multicast features, both hosts and routers must have multicast capability. On hosts, the Internet Group Multicast Protocol (IGMP) is now part of Windows. In routers, there are several routing protocols that facilitate multicast routing. The Distance Vector Multicast Routing Protocol (DVMRP), Protocol Independent Multicast (PIM) and Multicast Open Shortest Path First (MOSPF).
It is probable that performance guarantees are only required for a portion of the network's traffic, such as the multimedia applications. To accommodate all types of traffic on the same network, RSVP is used to allocate some fixed portion of the available bandwidth to the real-time traffic, while leaving some bandwidth available for the regular data LAN traffic.
In addition to a bandwidth reservation, RSVP lets real-time traffic reserve the network resources necessary for consistent latency. To do this, routers sort and prioritize packets before transmission on to the network media. To deploy RSVP, you should determine the amount of available bandwidth that can be reserved by RSVP streams, the amount set aside for low-volume, bursty data traffic and the amount of bandwidth allowed per host for a reserved application flow.
Cisco has implemented RSVP as a means of providing performance guarantees over Ethernet in its routing devices. Assuming that you have version 11.2 or higher of Cisco's Internetwork Operating System (IOS), you can implement RSVP. The following configuration enables RSVP on Ethernet 0, with 1,000-Kbps total reserved for RSVP, and no single RSVP flow to reserve more than 100 Kbps:
Interface ethernet 0
ip rsvp bandwidth 1000 100
As you can see, RSVP is simple to set up and administer and provides improved performance guarantees for multimedia applications that are transported over Ethernet networks. When further enhanced by an application's use of RTP, better results can be achieved. Given that Ethernet has been extended to deliver 100 Mbps and Gigabit Ethernet is on the horizon, there seems plenty of life left in this technology to meet the demands of multimedia applications.

 


 
Books24x7.com, Inc © 2000 –  Feedback